COMMENT ⊗   VALID 00001 PAGES
C REC  PAGE   DESCRIPTION
C00001 00001
C00002 ENDMK
C⊗;
∂12-FEB-76  1527	FTP:MACRAK at MIT-ML
Date: 12 FEB 1976 1823-EST
From: MACRAK at MIT-ML
To: JRA at SU-AI

	Herein is my first installment of comments on the lisp
book.  Let me first explain my general prejudices and approach.
Many of my comments turn out to be defenses of the status quo,
which has of course served us well, but may not, in your view,
be pedagogically or conceptually sound.  My comments jump from
one level to another indiscriminately--first a punctuation error,
then a general outburst against, say, M-expr's, then a purist
remark about English usage.  I hope this will not prove to
dissuade you from looking for the meat of my critique.

	I also hope that my sometimes violently strong
language will be taken with a pinch of salt!

	About style, I feel that the book in general suffers
from a too informal writing style (contractions, word use,
conversational idioms (or idiomata, but that's a real stick-
in-the-mud usage).  I have felt free to write the present
comments in less formal language, however.

	You emphasize that there must be something beyond
mere programming to computer science and that training is not
education.  I agree.  But I feel that a book at about the
level of yours should serve also as an introduction, from
scratch, to programming.  (And I will contend later, on this
basis and others, that S-expr's should be introduced as the
'language' from the beginning.)  Learning programming the
right way from the start is much better than re-learning
programming after a bad start with, say, Fortran or PL/1
(or, God forbid, APL).  I have found in my personal experience
that teaching Lisp to novices is no more difficult than teaching
basic, and that the idea of function value rather than assignment,
if taught immediately, easily grabs the imagination of the
student.  Moreover, Lisp teaches the user not to expect a
slew of unrelated, seemingly tremendously expressive 'features'
which even the simplest other languages seem to suffer from.

p. 3 (by the way, are page/line refs best, or section/paragraph,
or what) para. 2   'many languages now offer themselves with
better notation, more efficient running code, or larger
varieties of data structure'--I see very few problems with
notation in Lisp, our compiler (perhaps not others) produces
excellent code (given the data structures--no bit packing
'black magic') which in fact is better than DEC's Fortran
compiler (admittedly not one of the world's great optimizers);
as for larger varieties of data structure, that's mainly a
matter of bit-packing efficiency, which could doubtless
be attained at the cost of a few extra functions.
		nota bene: the few extra functions would not
			be at all outside the spirit of Lisp.
		Types, unfortunately, don't seem to have 
		terribly clear semantics in the Lisps with
		which I'm familiar beyond atoms, lists,
		and numbers (but see Muddle for the opposite
		extreme)

p. 6/para 1
wasn't there a cacm paper recently with a historical comparison
of the development of cs and math? (not terribly relevant)

you note that the syntactic description of the integers is
'quite superficial and completely inadequate for the
purposes [shouldn't this be singular?] of discussing properties
of the integers' [or even 'inadequate for discussing...]
and 'clearly all we know' for 'all of the information..'
Yet you begin the discussion of S-expr's with the syntactic
description.

In re induction, isn't your treatment a bit too long for the
audience to which you are addressing yourself--they must have
seen this countless times before in logic, foundations, set
theory, ... and for cs types, bnf must be second nature.

A matter of style: these 3-digit acronyms and abbreviations
don't appeal to me (PRF, IND, REC, CBN, CBV) especially when you
hide the meaning (Call By Name...)

About BNF--why do you call '><' 'followed by'?  Wouldn't
it be easier to say that juxtaposition indicates 'followed by',
and that <...> indicates a meta-linguistic quantity?

p. 9/para 3
'we have begun to see the difference between an abstract
object and its representation'  but we have not seen the
relation between the two, which is critical!!  In the
numeral/number case, the mapping is especially painful, viz.:
0 -> 0
1 -> s(0)
...
define add:
(lambda (a b) (cond ((equal b 0) a) (t (s (add a (sub1 b))))))
succ-no-sub1:
(lambda (x) (cadr x))
s:
(lambda (x) (list 's x))
mul:
(lambda (a b) (cond ((equal b 0) '0) (t (add a (mul a (succ-no-sub1 b))))))

<digits><digit> -> (add m<digit> (mul m10 m<digits>))
wehre mx means the mapping of x into s... form.

Blech!

Now back to the business at hand.

So, you established that the syntactic description is a mess.
Why then begin with syntax for S-expr's?  And more especially,
why worry about the silly details of what an atom looks like?
BNF belongs to Algol and other languages that have
messy syntax.  The description 'a string of letters and digits,
with at least one letter' for 'literal atom' (which we call a
'symbol' around here, by the way, although loosely 'atom'
passes--sometimes 'atomic symbol') seems sufficient.  Then
on the next page you proceed to talk about the possibility
of floating point numbers confusing the '.' issue.  Now
that's both outside your central topic and trivial on its
own merits!  Some implementations allow the base to be changed
to 'roman' (ours--a crock introduced by Guy Steele).
Perhaps that too should be mentioned!

Approach to S-expr's

My approach would probably be to start with the idea of
'ordered pair' generalized to tree on atoms, and then
[this is a sort of motivational approach]
a search for good representations--first graphic trees,
then dotted pairs, leaving 'box notation' for the chapter
on implementation.


Well, that's all for now--time to go home.
This pretty much covers my comments through sec. 2.3,
inclusive.  I've read into chapter 3, and scribbled comments,
but I don't have the time to type them now, so here's
this installment, so that you can tell me what to do
about my style of criticism!
-------